…llaumeGomez

Rollup of 9 pull requests

Successful merges:

 - rust-lang#126039 (Promote `arm64ec-pc-windows-msvc` to tier 2)
 - rust-lang#126075 (Remove `DebugWithInfcx` machinery)
 - rust-lang#126228 (Provide correct parent for nested anon const)
 - rust-lang#126232 (interpret: dyn trait metadata check: equate traits in a proper way)
 - rust-lang#126242 (Simplify provider api to improve llvm ir)
 - rust-lang#126294 (coverage: Replace the old span refiner with a single function)
 - rust-lang#126295 (No uninitalized report in a pre-returned match arm)
 - rust-lang#126312 (Update `rustc-perf` submodule)
 - rust-lang#126322 (Follow up to splitting core's PanicInfo and std's PanicInfo)

r? `@ghost`
`@rustbot` modify labels: rollup

Rollup merge of rust-lang#126075 - compiler-errors:remove-debugwithinfcx, r=lcnr

Remove `DebugWithInfcx` machinery

This PR removes `DebugWithInfcx` after having a lot of second thoughts about it due to recent type system uplifting work. We could add it back later if we want, but I don't think the amount of boilerplate in the complier and the existence of (kindof) hacks like `NoInfcx` currently justify the existence of `DebugWithInfcx`, especially since it's not even being used anywhere in the compiler currently.

The motivation for `DebugWithInfcx` is that we want to be able to print infcx-aware information, such as universe information[^1] (though if there are other usages that I'm overlooking, please let me know). I think there are probably more tailored solutions that can specifically be employed in places where this infcx-aware printing is necessary. For example, one way of achieving this is by implementing a custom `FmtPrinter` which overloads `ty_infer_name` (perhaps also extending it to have overrideable stubs for printing placeholders too) to print the `?u.i` name for an infer var. This will necessitate uplifting `Print` from `rustc_middle::ty::print`, but this seems a bit more extensible and reusable than `DebugWithInfcx`.

One of the problems w/ `DebugWithInfcx` is its opt-in-ness. Even if a compiler dev adds a new `debug!(ty)` in a context where there is an `infcx` we can access, they have to *opt-in* to using `DebugWithInfcx` with something like `debug!(infcx.with(ty))`. This feels to me like it risks a lot of boilerplate, and very easy to just forget adding it at all, especially in cases like `#[instrument]`.

A second problem is the `NoInfcx` type itself. It's necessary to have this dummy infcx implementation since we often want to print types outside of the scope of a valid `Infcx`. Right now, `NoInfcx` is only *partially* a valid implementation of `InferCtxtLike`, except for the methods that we specifically need for `DebugWithInfcx`. As I work on uplifting the trait solver, I actually want to add a lot more methods to `InferCtxtLike` and having to add `unreachable!("this should never be called")` stubs for uplifted methods like `next_ty_var` is quite annoying.

In reality, I actually only *really* care about the second problem -- we could, perhaps, instead just try to get rid of `NoInfcx` and just just duplicate `Debug` and `DebugWithInfcx` for most types. If we're okay with duplicating all these implementations (though most of them would just be trivial `#[derive(Debug, DebugWithInfcx)]`), I'd be okay with that too 🤔

r? `@BoxyUwU` `@lcnr` would like to know your thoughts -- happy to discuss this further, mainly trying to bring this problem up

[^1]: Which in my experience is only really necessary when we're debugging things like generalizer bugs.